The present invention relates to the testing of an electronic control unit (ECU) and a physical unit which are used in an automobile and the like. More particularly, the present invention relates to software-based testing and emulation of multiple ECUs and to the software-based testing of a physical unit simulator.
An automobile, in its early stage, that is the early 20th century, was composed of: an engine as a power source; and mechanical parts including a brake, an accelerator, a steering wheel, a transmission and a suspension, including almost no electrical mechanisms except for an ignition plug for the engine and a headlight.
However, around the 1970s, there arose the need to efficiently control the engine in preparation for air pollution, oil crisis and the like. Thus, an ECU started to be used for engine control. The ECU generally includes: an input interface for executing, for example, A/D conversion of an input signal from a sensor; a logic operation part (microcomputer) for processing a digital input signal according to a predetermined logic; and an output interface for converting the result of the processing into an actuator operating signal.
A significant proportion of a recent automobile is now occupied not only by the mechanical parts but also by electronic parts and software. This includes such examples as control systems for the engine and the transmission, an anti-lock breaking system (ABS), electronic stability control (ESC) and power steering, wiper control, a security monitoring system and the like. A development cost for the electronic parts and software is said to be 25% or 40% of the total and accounts for 70% in a hybrid car.
Multiple ECUs are arranged to perform electronic control. The ECUs are connected to each other through an in-vehicle network, for example, a controller area network (CAN). Moreover, the engine, the transmission and the like, which are objects to be controlled, are connected directly to the respective ECUs through wirings.
The ECU is a small computer and operated according to an interrupt from a sensor input or the like. Meanwhile, the engine and other mechanical systems continuously execute mechanical operations. In other words, a computer digital system and a mechanical physical system execute cooperative operations in parallel in a single system such as an automobile. Naturally, software supporting those operations has become more and more complicated. Thus, there is an urgent need to achieve a mechanism not only for verifying the operations of a single ECU but also for verifying the operations of multiple ECUs at the same time.
Here, examples of the sensor for inputting signals to the ECU include: a temperature sensor for measuring an engine temperature and the like; a pressure sensor for estimating a pressure sucked into the engine; a throttle position sensor for measuring a stepping amount of an accelerator pedal; a steering angle sensor; a vehicle height sensor; a rotation speed sensor; a knock sensor; an acceleration sensor; a flow rate sensor; an oxygen sensor; a lean air fuel ratio sensor; and the like.
Meanwhile, examples of actuators driven by an output signal coming from an ECU include an electromagnetic solenoid, a motor and the like. The solenoid is used, for example, for an injector of the engine, shift control of the transmission, brake valve control, door lock and the like.
The motor is used mainly as a servo mechanism for a starter of the engine, fuel control of the engine, a brake hydraulic pump, steering angle control, steering wheels, wipers, power windows, seat belts, air bags, and the like.
A technique that has been used for such testing is called “hardware in the loop simulation” (HILS). Particularly, an environment for testing all the ECUs in the automobile is called a full-vehicle HILS. In the full-vehicle HILS, a test is conducted in a laboratory according to a predetermined scenario by connecting an actual ECU to a dedicated hardware device for emulating an engine, a transmission mechanism and the like. An output from the ECU is inputted to a monitoring computer and further displayed on a display. Thus, an operator conducting the test checks if there is any abnormal operation while looking at the display.
However, in the HILS, the dedicated hardware device is used and physical wiring connection between the device and the actual ECU is required. Thus, preparation is time intensive. Moreover, when a test is conducted by replacing the ECU with another one, the device and the ECU have to be physically reconnected to each other, thus requiring even more time. Furthermore, since the test uses the actual ECU, it takes actual time to conduct the test. Therefore, it takes large amounts of time to test many scenarios. Moreover, the hardware device for emulation of the HILS is generally very expensive.
Therefore, a technique of testing by using software configuration without using the expensive hardware device for emulation was developed. This technique is called “software in the loop simulation” (SILS), in which all components to be installed in the ECU, such as a microcomputer, an I/O circuit and control scenarios, are configured by use of a software simulator. According to the SILS, a test can be executed without the hardware of the ECU.
Here, description will be given of an example where an ECU emulator and a physical unit simulator, particularly an engine simulator, operate in cooperation with each other. Note that, for convenience, operations of the ECU emulator and the engine simulator will be described below as operations of an actual ECU and an actual engine. First, at 30 degrees before a piston reaches a top dead center with the rotation of a crankshaft, the engine generates an interrupt to the ECU. Upon receipt of the interrupt, the ECU calculates fuel injection timing and gives an injection instruction at the calculated timing. Upon receipt of the instruction, the engine injects a fuel and subsequently calculates movement of a crank rotated by inertia. Thereafter, when the piston reaches 30 degrees before the top dead center again, the engine generates an interrupt to the ECU to notify the ECU of the fact. Then the ECU calculates ignition timing and gives an instruction to the engine at the timing. In response to the instruction, the engine explodes the fuel inside a cylinder and starts to calculate new rotation movement. Such operations are repeatedly executed.
Such alternating operations of the engine and the ECU are considered as a critical path. Thus, when discrete events in the automobile are simulated in parallel, the presence of such a critical path inhibits sufficient parallelism from the viewpoint of computational performance. Therefore, in the full-vehicle HILS using a computer of a multiprocessor system, even if individual CPUs are assigned to multiple ECU emulators, respectively these CPUs can only exert the performance nearly equivalent to that produced by a single CPU serially calculating the multiple ECU emulators and an engine emulator in the worst case scenario.
One of the simplest methods for consistently operating multiple logical processes in parallel is to operate each of the logical processes according to overall commands. However, this method requires synchronization processing even when no event such as an interrupt is generated. Thus, a processing load is increased and the processing is slowed down.
In discrete event simulation for asynchronously operating the multiple logical processes in parallel, communication between the processes is performed by transmitting and receiving messages of events with timestamps. In this event, as the timestamp, a common time in the entire simulation system is recorded. Here, such a time is called a simulation clock. For each of the logical processes, it is independently determined at which point of the simulation clock the processing is performed. The points where the processing is performed do not always have to coincide with each other. However, when the logical processes perform the processing in cooperation with each other, the logical processes are required to perform the processing in the order of the timestamps. As long as the processing is carried on as described above, the processing can be carried on in the same manner as the case of serial processing of the entire system.
As one example of asynchronous processing, there is conservative synchronization. In this method, events are always processed in the chronological order of timestamps.
An example of the conservative synchronization will be described. It is assumed that a certain logical process has queues from two upstream processes. An event with a time t1 and an event with a time t2 have arrived in one of the queues. The time t1 is older than the time t2. Moreover, nothing has arrived in the other queue. In this case, the logical process is supposed to process the events sequentially from the event with the time t1. However, an event with a time older than the time t1 may arrive in the other queue from upstream. In other words, it is not guaranteed that the time t1 is the oldest. Thus, the processing cannot be carried on. Particularly, in a configuration having a transmission-reception loop between the logical processes, such a configuration may cause deadlock.
In order to avoid such a situation, there is a known method using a null message. In this method, in order to indicate that the upstream logical process does not generate any event until a certain time, a null message having the time is sent to a downstream logical process. Such a time is called a lower bound on the timestamp (LBTS). Upon receipt of such a null message, the downstream logical process can carry on the processing by comparing the timestamp of the event that has arrived with the LBTS and regarding an event with a timestamp older than the LBTS as determinate.
Additionally, there is a known method using no null message called optimistic synchronization. In this method, processing is executed on the assumption that, when a certain logical process has queues from two upstream processes, an event with a time t1 and an event with a time t2 have arrived in one of the queues and the time t1 is older than the time t2 and when nothing has arrived in the other queue, the event with the time t1 is tentatively set as the oldest. Thereafter, when an event with a time older than the time t1 arrives in the other queue, a series of processing starting from the event with the time t1 is sequentially cancelled by sending a reverse message. Subsequently, a new event with a time older than the time t1 is processed. In this method, the events to be outputted from the logical process are temporarily not necessarily in the order of the timestamps. However, those events are guaranteed to be finally set in the order of the timestamps by rollback.
By use of the methods as described above, the events can be transmitted in a correct order while avoiding the deadlock. However, such methods still cannot avoid serialization of processing. Thus, the processing still cannot be speeded up.
Japanese Patent Application Publication No. Hei 6-161987 is directed to implementation of artificial ECU hardware and thus enable real machine evaluation by software, and discloses simulation of hardware having desired functions by changing over a matrix switch.
Japanese Patent Application Publication No. Hei 11-14507 is directed to enablement of desk verification of logic of an entire vehicle, and discloses a vehicle simulation device including an engine control simulator (ECU) and a vehicle control simulator. The ECU calculates control parameters of an engine model and transmits the result of the calculation to the vehicle control simulator. The vehicle control simulator uses the control parameters sent from the ECU to calculate a state quantity of each part of a vehicle model, and sends the result of the calculation back to the ECU. The vehicle model includes a driver model, an inlet system model, a fuel system model, a combustion system model, an engine temperature estimation model, a drive system model, a catalyst model, an A/F sensor model and a rear O2 sensor model. The driver model has vehicle speed pattern input means for inputting change pattern of a target vehicle speed.
Japanese Patent Application Publication No. 2001-331346 provides a simulator capable of debugging a control program as though a real machine exists, even if the real machine has not been completed yet, and discloses the following. Specifically, control information is written into a memory by a control CPU writes control information into a memory, first. Then, a CPU for simulation reads, through a bus, the control information written into the memory, executes simulation based on the control information, and then writes a result of the simulation is written into the memory through the bus. Subsequently, the control CPU reads the simulation result written into the memory.
Japanese Patent Application Publication No. 2003-316603 relates to a verification system capable of verifying a program without waiting for completion of a real machine device even in the case where program development precedes hardware development of a real machine, and discloses the following. Specifically, in this verification system, a bridge is provided between an ICE debugger supporting specifications of the real machine device and a virtual device for simulating the specifications of the real machine device supporting a new program. Here, the bridge performs conversion processing or the like so as to adapt commands or the like from the virtual device to the ICE debugger.
However, the documents described above make no reference to a technology of synchronization between logical processes.
Japanese Patent Application Publication No. 2008-1261 discloses a data processing device for vehicle control that can be kept always mounted on a vehicle and is capable of performing data collection for development/evaluation and simulation with the following configuration. Specifically, in this data processing device, a data transfer/reception processing part 5 having a multi I/O data buffer function temporarily holds data received by a data receiving part and outputs the data to an I/O terminal part in an initial setting state. Moreover, the data transfer/reception processing part 5 temporarily holds collection result data inputted to the I/O terminal part when the initial setting state is switched to a simulation state by a simulation command. Thereafter, an arithmetic processing part 6 executes a vehicle control operation based on the data temporarily held by the data transfer/reception processing part 5 and outputs vehicle control data as a result of the operation to a bus connection terminal part.
Japanese Patent Application Publication No. 2008-84121 discloses a configuration in which: a plurality of slave management devices SPC each managing environmental conditions of simulation in a simulator for executing predetermined simulation are respectively provided in association with a plurality of simulators SM; and a master management device is connected to all the slave management devices SPC via a network and performs integration management of the environmental conditions of the simulation in the plurality of simulators via the slave management devices.
If the above technologies described are combined, high-speed simulation would still be difficult due to constraint to serial properties of operations in a full-vehicle SILS.